xen/arm: vgic-v3: Correctly retrieve the vCPU associated to a re-distributor
authorJulien Grall <julien.grall@citrix.com>
Tue, 29 Sep 2015 14:44:40 +0000 (15:44 +0100)
committerIan Campbell <ian.campbell@citrix.com>
Thu, 1 Oct 2015 12:48:51 +0000 (13:48 +0100)
commit9b9d51e98edb8c5c731e2d06dfad3633053d88a4
tree2aa6f1eabffff7a9cf3aab74a0dee4ea0d5eb853
parentea7d70ef27430002f7d1e2e07c102cd05e18f0eb
xen/arm: vgic-v3: Correctly retrieve the vCPU associated to a re-distributor

When the guest is accessing the re-distributor, Xen retrieves the base
of the re-distributor using a mask based on the stride.

When the stride contains multiple bits set, the corresponding mask will be
computed incorrectly [1] and therefore giving invalid vCPU and offset:

(XEN) d0v0: vGICR: unknown gpa read address 000000008d130008
(XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffffffc00032362c
gva=0xffffff80000b0008 gpa=0x0000008d130008

For instance if the region of re-distributor is starting at 0x8d100000
and the stride is 0x30000, an access to the address 0x8d130008 should
be valid and use the re-distributor of vCPU1 with an offset of 0x8.
Although, Xen is returning the vCPU0 and an offset of 0x20008.

I didn't find a way to replace the current computation of the mask with
a valid one. The only solution I have found is to pass the region in
private data of the handler. So we can directly get the offset from the
beginning of the region and find the corresponding vCPU/offset in the
re-distributor.

This is also make the code simpler and avoid fast/slow path.

[1] http://lists.xen.org/archives/html/xen-devel/2015-09/msg03372.html

Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arch/arm/vgic-v3.c